1. Field of the Invention
The present invention is related to monitoring file integrity, and more particularly, to a more reliable method of using timestamps to verify whether or not a file has been modified.
2. Description of the Related Art
File integrity is important in many computer applications. There are many applications where knowledge of whether the file has been modified is important—for example, where the user is trying to restore the state of the system (or the state of an application) to what it was at some earlier point in time. Also, files can be changed accidentally or deliberately, the file can overwritten, portions of files can be overwritten accidentally or intentionally, etc. For example, in the context of virus protection and protection from other malware risks, it is important to know whether or not a particular file has been modified.
There are two conventional methods for testing whether a particular file has been modified. The first method involves the use of timestamps. All modern operating systems have a facility for keeping track of the last date and time when the file was modified. However, the problem with relying solely on this operating system utility is that a user application normally has rights to modify the timestamp directly. Thus, a malicious application could easily take advantage of this fact by saving the earlier timestamp of the file, and, after modifying the file, replacing the new timestamp with the timestamp of that file prior to the modification. Therefore, a check that relies only on the timestamp would show that the file had not been modified, when, in fact, it had been. At the same time, disabling the ability of user applications to change file timestamps is often impossible, since there are legitimate applications that may need to access and alter the timestamps.
FIG. 1A illustrates a timeline of how the monitoring that only relies on the files systems timestamp function can be subverted. As shown in FIG. 1A, at the time t1, the file has a Timestamp A. After that point in time, a request to the file system will produce a response that corresponds to the Timestamp A.
Subsequently, the file has been modified, and now has a Timestamp B, at the time t2. At that point, a request to the file system will result in a response that corresponds to the Timestamp B.
At the time t3, a malicious application directly accesses the timestamps and modifies the timestamp from B back to A, therefore, a request to the file system after that point will produce a response that corresponds to the timestamp A which does not reflect the fact that the file has been modified in the meantime.
Another approach to tracking file modifications involves the use of various functions, typically one-way functions, such as hashes. A hash is a one-way transformation of a file into a (usually) much smaller binary value, so that a change in the content of the file would normally produce a different hash value. The MD5 hash function is frequently used in many computer applications of this kind. The problem with this approach is that generating hash values is a relatively computationally intensive task, particularly for large files. For example, many current applications require loading of multi-megabyte files into memory, prior to execution. If it were necessary to generate a hash of these files every time the application were launched, the user would suffer from a long delay before the application actually is up and running. Today, most users would find this annoying and irritating.
Accordingly, there is a need in the art for a fast mechanism that permits checking whether or not a file has been modified.